What Is JWT and Why Should You Use JWT

https://www.youtube.com/watch?v=7Q17ubqLfaM&list=PLZlA0Gpn_vH9yI1hwDVzWqu5sAfajcsBQ&index=1

hello everyone my name is Kyle and this
is web dev simplified now if you're
anything like me you've probably heard
of JWT you've maybe even seen a few
videos on it but you still have
absolutely no idea how JWT really works
or even why you would actually want to
use it so today in this video I'm going
to answer all of those questions for you
first I'm gonna tell you what JWT is
then I'm going to talk about why you
should use JWT and finally I'm gonna
show you exactly how JWT works and how
you can use it yourself so let's get
started now first before we can get into
the nitty gritty details of exactly how
JWT works we need to understand what JWT
is used for and JWT is just for
authorization not authentication they're
slightly different with authentication
what you're doing is you're taking in a
username and a password and
authenticating to make sure that
username and password is correct it's
like logging a user in but authorization
is actually making sure that the user
that sends request to your server is the
same user that actually logged in during
the authentication process
it's authorizing that this user has
access to this particular system and the
way that this is normally done is by
using session so for example you have a
session ID that you send down in the
cookies of the browser and then every
time the client makes your request they
send that session ID up to the server
and the server checks its memory says ok
what user has that session ID it finds
that user and then it does the
authorization to make sure the user has
access
but JWT instead of actually using these
cookies it uses a JSON web token which
is what JWT stands for to do the
authorization let's actually look at a
quick graph to explain the differences
first we're gonna take a look at a more
traditional user login system that uses
sessions and cookies to store the user
so the first thing that happens is the
user actually logs in from the client by
posting to some kind of login service
with their email password for example
and as soon as that gets to the server
what's going to happen is the third
server is going to do the authentication
to make sure that that user is correct
and if that user is correct with the
email password what they're going to do
is they're actually going to store that
user inside the session which is stored
in the memory of the server and they're
going to get a unique ID that
corresponds with that
heart in memory and they're gonna send
that ID back to the browser using a
cookie so that the browser always has
that session ID that it sends up to the
server every single time it makes
requests so for example down here when
the client needs to make another request
for example they want to go to a new
page in the application that session ID
gets sent along with the cookie that it
corresponds with so since it's a cookie
it gets sent along to the server and at
the server what happens is it's going to
do the calculation is going to go into
the session memory and it's going to
check do I have something in memory that
corresponds to this particular ID that
gets sent to me if so then it's going to
say this is the user that corresponds
with that ID and it has access to that
user to store that user in the session
memory so now the application knows this
is the user I'm working with are they
authorized to access this information if
they are authorized then it sends the
response back to the browser saying ok
everything's good
here's the information you were looking
for the other form of authentication we
have here is JWT so I'm going to get
these two we can see both of them on the
screen and it works very similarly at
the beginning we make a post request
with our email password and we send that
along to the server just like before but
instead of storing information on the
server inside session memory what
happens is the server creates a JSON web
token this JWT and it actually encodes
and C realises that and signs it with
its own secret key so the server knows
that if you tamper with it then it's
invalid it can actually check that based
on the fact that it's signed it with a
secret key then it takes that JSON web
token and it sends it back to the
browser and notice the main difference
here is nothing is stored on the server
the server doesn't store the user
nothing actually happens on the server
this JWT has all the information about
the user built into it so it sends that
JWT back down to the browser and the
browser can choose to store that however
it wants for example you could do cookie
storage and it would work very similarly
to over here but anyway that happens the
client is then going to send a request
to the server and they're gonna make
sure to include that JSON web token so
that it knows what user is
authenticating with and the server what
it does is it's signed to that JSON web
token with its own secret key so what it
does is it verifies that this JSON web
token has not been changed since the
time that it signed it because if for
example the client changed it
changed the user information in that
JSON web token the server will now know
and they can say that it's invalid but
if for example nothing actually got
tampered with the JSON web token is
correct now what happens is it just DC
realises that JSON web token and it says
okay this is the user information it's
stored in that token already so it knows
exactly what to do with that user and if
that user is authorized to use that
resource it'll send that response back
down to the client now really the main
difference that you're going to is
notice between these two is that in the
session version the information about
the user is stored on the server so the
server actually has to do a lookup to
find the user based on the session ID
but with the JWT the JSON web token what
happens is the user information is
stored in the actual token which means
it's stored on the client and the server
doesn't have to remember anything which
is great because it means you can use
the same JSON web token across multiple
servers that you run without having to
run into problems where one server has a
certain session and the other server
doesn't I'm gonna go into a lot more
depth on why this is really important
and how this makes JWT so powerful later
in this video but next I want to show
you exactly how JWT actually signs its
tokens and how it can store the user
information Here I am on a site called
JWT IO and I'm gonna link this in the
description so you can mess around with
it yourself if you want but essentially
what we have is two different panes on
the Left we have the encoded version of
our JSON web token this is what you send
to and from the client and this is how
you authorize the user for different
resources on the right we have the
decoded version of that JSON web token
which has three distinct parts it has a
header which determines the algorithm
that you're actually using to encode and
decode this it has the payload which is
just going to be all the information you
store it in the token and lastly and
most importantly we have this signature
which allows us to verify that the token
hasn't been changed by the client before
it gets sent back to us so the very
first thing we want to look at is the
header and as you can see over here the
header is always before the very first
period inside of this and it's just base
64 encoded so here we have our header
and this is just determining our
algorithm and our JWT token type and
really this is only useful for our
signature portion at the very end where
we're verifying it so we're going to
kind of skip over this and go on to the
second so
which is our data and this comes in
between the two other periods it's
really nice JWT actually separates
things by periods so it's very visually
easy to see what the different sections
are so here we have our data section as
I mentioned and this is where you're
going to put all of your different data
for your application and there's some
very common fields that you're gonna see
across all different JW T's for example
this SUV which stands for subject this
is just going to be most likely the ID
of the user you're authenticating lots
of times you would store this in the
session inside of your database or
inside of your server but here you're
just storing this ID directly in the
token you're sending back to the user
next we have other fields you can put
anything you want here for example we
just have a name field here for the
users name but like I said you can put
anything in this data component these
are just some common fields that you've
made all the time see another one that's
really common is IAT which stands for
issued at and really what this is saying
is when the token was created this is
really useful if you want to actually
expire tokens and you will notice a lot
of tokens we'll also have something
called exp or e8e
which is going to stand for expired at
and this is just the date that the token
no longer becomes a valid and it's
important a lot of times to have an
expire date on your tokens because
otherwise someone else could take your
token and use that to authorize
themselves as you and if it doesn't
expire they can just use that forever
and ever and ever always saying that
they're you even though they're actually
or not so you need some way to expire
your tokens so that sort of activity it
does not happen to your users lastly
most importantly we have this verify
signature at the bottom and what this is
going to do is it's going to allow you
to actually verify that the user did not
mess with the token before it got sent
back to you and the way that it does
that is it actually takes the first two
portions of the token so takes your
header and it base64 encode it so you
have this read section and then it adds
a period and you have the purple section
which is the base64 encoded payload so
base64 encode both of those sections and
combines them with period essentially
all it does is it takes your header and
it takes your payload and it combines
them together so you have all of the
data as it was when you sent it down to
the user and then what it does is it
uses the algorithm which is defined in
the header here HS 256 you can change
this algorithm if you want but this is
just a good one to use it uses that
algorithm and actually a secret
which you can define yourself for
example we could just find a key called
secret that's a terrible secret key but
just for this example we'll use it and
then what happens is it uses this
algorithm up here HS 256 and it encodes
your data portion so essentially all of
your header information and your data
information it takes all of that and it
encodes it using your specific secret
key and that's what this blue section is
it's the encoded version of your data
that you have sent to the client so now
if the client changes the data for
example they remove this six from their
data now you can see immediately the
signature is not going to match because
when the client or when the server gets
the information from the client what
they're gonna do is they're going to
decode this top section they're going to
combine it together
down here as you can see they're gonna
base64 encode the header they're gonna
base64 encode the payload and then
they're going to hash it with the
particular algorithm and they're gonna
check does it match the last portion of
the key if it does match the last
portion of the key then you know that
the user did not mess with anything but
if when they hash it as you can see up
here they get a different result for
example when you hash this information
you are not going to get this blue
section so they know immediately that
this key has been tampered with and that
the data in the JWT is no longer valid
and that's why you can actually store
user information on the client and you
can actually trust that they haven't
changed it because they would have to
have your secret key if they ever did
get access to your secret key then they
would be able to fake changes but that's
actually not going to happen as long as
you safely store your secret key on your
server and unaccessible to other people
outside of that server and hopefully
that made sense this really essentially
works a lot like password hashing in the
fact that the header appear and the
payload are actually combined together
and then hashed in a way that they
cannot be unhatched and the way that it
checks here this blue section is just
the hash of those two so anytime your
data is changed the two hashes will no
longer match which means that you know
that the data that the client is sending
you is not the same as what you
originally sent them yourselves only
when those two information pieces match
do you know that they're exactly the
same now that we talked a lot about how
JWT works what it is we should finally
talk about why you would want to use JWT
and let's take a look at a very simple
example of one of them
common use cases of JWT here we have two
different servers we have a bank that
owns a server that runs all of their
banking applications their banking
website all of the bank information you
could think of but they also own a
separate server and this takes care of
all of their retirement plans they allow
people to invest and do retirement plans
on a completely separate web application
but they want their users that log in to
the bank
to also be able to be automatically
logged into the retirement account so
when they switch from the bank to the
retirement server they don't want the
user to have to re log back in
especially if they make this transition
very seamless to the user so it looks
like they're on the same application
this is really common in a lot of larger
scale industries and applications and
companies so what happens is the client
makes a request here to the bank they
say ok I want some bank information bank
information blah blah blah they do all
their banking stuff and then finally
they get to the point where they
actually want to access the retirement
information and if you have a normal
session based server what happens as
your session is stored here inside of
the bank and not inside of the
retirement server so what happens is
your user needs to log back in because
they need to be able to have their
session stored on the retirement server
because the session ID from the client
is not found in the retirement server
but when you're using JWT
if you share the same secret key between
both your bank and your retirement
server then all you need to do is send
the same JWT from the client to both of
them and you'll be authenticated both
times without having to re log back in I
know this is a little bit confusing to
wrap your head around at first but
essentially we're storing the user
information on the client while in the
old cookie session version we store it
on the server and since we have two
separate servers we need to have the
information stored on both of them but
that's not very easy to do or very
possible so what usually happens is you
have to store it on one place and then
the user has to real aughh in when they
go to the other place but with JWT since
the user information is stored in that
token on the client it doesn't matter if
they access the bank server the
retirement server or any other server
that this bank owns they're still going
to be logged in because they have the
same exact token and all the server's
can recognize that token as long as they
have that same secret key on the server
another time that this is really used
same kind of example with multiple
servers is let's say for example we had
two bank servers the bank was very large
and they needed two different servers to
build a handle all of the users that
were coming to the server and they have
some form of load balancer out in front
that distributed traffic to the
different servers let's say that your
client was accessing server a for a
while and then this server it got really
busy so it moved that client over to
server B over here their session is no
longer stored on server B it's only on
server a so the user has to real aughh
back in when this happens and with JWT
you don't have to worry about that
because like I mentioned earlier the
user is stored on the client that's
really the important thing about JWT is
the user is stored on the client so no
matter how many different servers you
have no matter how many different
applications load balancers or anything
that you have it doesn't matter if the
user can always authenticate with any of
those servers as long as you have the
same secret key between them another
instance where this is really useful is
just you have a lot of really small
services such as micro services where
you may have an API you may have an
actual web server maybe even something
else you can use that same JWT token
from the client to authenticate with any
of those different micro services all
across your different architecture and
now you know literally everything you
need to know about JWT if you want me to
make a video explaining JWT in nodejs
let me know down in the comments below
because I would love to make a tutorial
on that for you also make sure to check
out my other videos linked over here and
subscribe to the channel for more videos
of me simplifying the web for you thank
you very much for watching and have a
good day
